Add Cloudflare preview deployments for pull requests - #14
Merged
Conversation
Adds a CI job that uploads a new Worker version (wrangler versions upload, not a full deploy — never touches the production/Active deployment) on every pull request, tagged with a stable per-PR preview alias, and posts/updates the resulting preview URL as a PR comment. Also provisions the SESSION KV namespace that @astrojs/cloudflare's sessions feature auto-injects into the generated wrangler.json — it previously had no namespace ID, which would have hard-failed any real deploy regardless of this change (KV namespace IDs are not secret). Closes #4 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
🔍 Preview deployment: https://0beeafa1-blindtechmage-website.blindtechmage.workers.dev |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Preview DeployCI workflow that runs on every pull request (opened/synchronize/reopened) againstmain: builds the site, then uploads a new Worker version (wrangler versions upload, notwrangler deploy— this never touches the production/Active deployment) tagged with a stablepr-<number>preview alias, and posts (or updates, on later pushes to the same PR) the resulting preview URL as a PR comment.@astrojs/cloudflare's built-in sessions feature auto-injects aSESSIONKV binding into the generatedwrangler.json, but it had no namespace ID — that's a hard failure at deploy time (KV namespaceidis a required field), not something CI could work around. Provisioned a real KV namespace and added its ID towrangler.toml. KV namespace IDs are not secret (see Cloudflare's docs), so this is safe to commit.CLOUDFLARE_API_KEYrepo secret (a scoped API token, Workers Scripts edit only on this account — despite the legacy-sounding name) and a newCLOUDFLARE_ACCOUNT_IDrepo variable (not sensitive).Closes #4
Notes
RECAPTCHA_SECRET) don't block the preview: Workers secrets resolve at request time, not at version-upload time, so every route except the contact form's POST handler previews correctly regardless.Deploy Cloudflare Previewcheck on this PR is itself the first real test of the workflow.Test plan
npm run typechecknpm run lint(js + markdown)npm run buildnpm run test:unit(26/26 passing)npx wrangler versions upload --dry-runagainst the built config, locally, to confirm bindings resolve correctlyjs-yamlDeploy Cloudflare Previewcheck)